InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / 1992 / 92_404.txt < prev next >

Wrap

Text File | 1992-10-22 | 16KB | 383 lines

X3S3.3/92-404 Identified Inconsistencies and Proposed changes to ISO/IEC DIS 10747 ==================================================================== Source: ATN Project (via L. Boan, MITRE) 1. Asymetric release of resources It seems that the specified procedures to be performed upon closing a BIS-BIS connection (7.6.2) will result in a different handling of allocated resources associated with this connection within the local and the remote BIS. The following table summarizes the relevant events and the resulting reactions according to ISO/IEC 10747. Event Reaction by local BIS Reaction by Remote BIS ---- --------------------- ---------------------- Stop Event Deallocate all resources Maintain Sequence Number Send CEASE PDU Receipt of Incorrect PDU Send IDRP ERROR PDU Deallocate all resources Maintain sequence number Send CEASE PDU Receipt of IDRP Deallocate all resources ERROR PDU Maintain sequence number Send CEASE PDU Maintain sequence number Maintaining the sequence number requires that other information (resources) associated with the BIS-BIS connection has to be maintained, too. This will result on the one hand in a strongly asymetric release of resources and on the other hand in an inconsistent establishment of a new connection: This is due to the fact that after reinitiation of a connection, flow control is expecting PDUs arriving with sequence numbers following the last number used in the previous closed connection (7.5.2). In order to have a match on the sending and receiving sides both BISs require identical starting conditions. However, the BIS which has released all resources, will start with sequence number of "1", whereas the peer BIS is still holding the last used sequence number for incoming BISPDUs. Proposed solution ----------------- It is proposed that a BIS entering the CLOSED state shall release all resources associated with the previous connection. This will cater for identical starting conditions, amongst others with respect to the sequence number. Add to clause 7.6.1.1 last line: A BIS entering the closed state shall release all connection records associated with the previous connection. Alternate solution ------------------ Remove all references to allocation/deallocation of resources. 2. Establishment of a BIS-BIS connection If no BIS-BIS connection exists between a BIS pair, both BISs are in the CLOSED state. Upon receipt of a start event, the local BIS shall enter the OPEN-SENT state and send an OPEN PDU to the remote BIS (7.6.1.1). As the remote BIS is in the CLOSED state, the first column of Table 2 applies for the status of its FSM. This table indicates that the BIS shall stay in the CLOSED state upon receipt of the OPEN PDU and take no action. As there is no other event to leave this state except the start event, the opening of a connection requires a quasi-simulataneous action by systems management at the local and remote BIS. It is highly desirable to start the IDRP FSM in an autonomous way without requiring systems management actions at both ends of the connection. Note: Also, if the 2 BIS peer's timers are not correctly set up, each side may send an OPEN PDU, and time out before receiving an OPEN PDU from its peer. With a BIS's timers slightly out of adjustment, it may take multiple OPEN PDU exchanges to open a connection. Worse case, a BIS-BIS connection may never be established due to time-outs. If a system management function must be required to establish the connection on both sides, this function must also be coordinated to keep within the set time periods. Proposed solution ----------------- Modify the IDRP FSM in order to allow a BIS being in the CLOSED state to leave this state and to enter the OPEN-RCVD state upon receipt of an OPEN PDU without errors. Change clause 7.6.1.1. C) to If the BIS receives any BISPDU other than an OPEN PDU, with or without header error, the BIS shall ignore it and the FSM shall remain in the CLOSED state. d) If the local BIS receives an OPEN BISPDU, the BIS shall generate an initial sequence number (see 7.5.2), and shall send an OPEN BISPDU to the remote BIS. The sequence field of the OPEN PDU shall contain the Initial Sequence Number (ISN), with an acknowledgment of the remote BIS's OPEN PDU. The FSM shall then enter the OPEN-RCVD state. 3. CloseWaitDelay The CloseWaitDelay is defined as the constant time period of 150 seconds that the IDRP FSM waits after having entered the Close-Wait state before entering the CLOSED state for a given BIS-BIS connection (10.). Upon entering the Close-Wait state all entries in the Adj-RIB-In associated with the peer BIS are marked as unreachable (7.6.1.5). As no new BIS-BIS connections can be set up to the remote BIS before the FSM has entered the CLOSED state, no communicate is possible with this BIS for at least 150 seconds. The following table identifies the events that can cause the IDRP FSM to close a BIS-BIS connection,ie to enter the CLOSE-WAIT state, and whether the new connection may be required immediately. Event Start new connection? Generation of Stop Event No, must wait for CloseWaitDelay timeout of by systems management 150 seconds Expiration of HoldTimer Yes, may wish to start a new connection immediately to continue communications Receipt of incorrect Yes, as the corruption of a PDU should not BISPDU cause a complete stop of communications Receipt of IDRP ERROR Yes/No (may depend on error) PDU Recept of CEASE PDU Unknown The above table indicates that BIS-BIS connections may be closed which require immediate establishment of a new one. Proposed solution ----------------- Define the CLoseWaitDelay as variable. The rationale for fixing the CloseWaitDelay to a value of 150 was, to guarantee that all outstanding BISPDUs associated with the previous connection will have expired before a new connection is opened, assuming a maximum lifetime of 128 seconds for ISO 8473 NPDUs. As the maximum lifetime of ISO 8473 PDUs may be much smaller depending on the inter-domain subnetwork characteristics, it seems appropropriate to allow the CloseWaitDelay time to be variable. A default value of 150 seconds could be recommended, however. 4. Inconsistent Flow Control mechanism for KEEPALIVE PDUs Section 7.5.3 c) of DIS 10747 states that an incoming KEEPALIVE PDU whose sequence value does not correspond to the expect one shall be discarded. As the sequence number value for a KEEPALIVE PDU is not incremented at the sending side (7.5.3 b), but the sequence number of the next expected PDU is increased at the receiving side after receipt of an UPDATE, RIB REFRESH, and OPEN PDU, a KEEPALIVE PDU following one of these PDUs will always be discarded. As a consequence, the HoldTimer may expire and the connection will close. Proposed solution ----------------- Remove the KEEPALIVE PDU from the third paragraph of section 7.5.3 c) in DIS 10747. Add the KEEPALIVE PDU to the forth paragraph of section 7.5.3 c.) 5. Maintaining of Sequence Numbers after Closing a Connection As described in 7.5.3 a) of ISO 10747, the initial value of the sequence number for outgoing BISPDUs will be chosen by the sender of an OPEN PDU in the process of establishing a connection. The initial value of the next expected sequence number for incoming PDUs will be derived from the OPEN PDU. This procedure seems to establish a completely new context for sequence numbers in the establishment phase of a BIS-BIS connection. The only rationale to keep the sequence number of the previously closed connection between the same BIS pair (7.5.2) and to use this sequence number as the initial one, is seen in the fact to exercise flow control for the exchange of OPEN PDUs. 1.As it is not completely clear in which cases the sequence number of the previously closed connection should be kept and re-used (7.5.2 discriminates between abnormal termination of a connection and conditions listed in Table 2 also contain abnormal termination conditions.) 2. And the specified procedure seems to be in conflict with the procedure defined for deallocating resources in the process of closing a connection it is proposed that an initial sequence number '1' be allowed for use when a connection is re-opened. Note also that the use of the CloseWaitDelay timer should guarantee that all outstanding BISPDUs are received by a BIS, before the BIS attempts to re-establish a connection. If a connection is re-established with sequence number one (or any other number), there should be no outstanding BISPDUs received using the sequence number corresponding to the previous connection. Text 7.5.2.c) should be modified to read: "If the connection is subsequently closed under the conditions provided in table 2, the sequence number should be set back to one. ..." 6. Closing a connection The closing of an IDRP connection can be initiated by an expiration of the HoldTimer. This should be listed in paragraph 7.6.2 in DIS 10747. 7. UPDATE PDU It is expected that the IDRP protocol may be implemented to run over very low bandwidth networks. The current ISO 10747 requires the a single UPDATE PDU be sent for each RIB-Att combination supported. For example, if 3 RIB-Atts were supported over a given route, 3 separate UDDATE PDUs would need to be exchanged between a BIS-BIS pair. Although this mechanism of one UPDATE PDU per RIB-att allows simplicity in mapping between the UPDATE PDU and the IDRP databases, for low bandwidth networks, this exchange may require a significant amount of time for a single BIS-BIS pair to stabilize their routes. Furthermore, if information is exchanged between BISs within a large topology, these separate UPDATE PDUs would require a long time period for the topology to stabilize in term of correct, up-to-date routing information. As the RIB-atts are provided in the initial OPEN PDU exchange, low bandwidth networks may find it in their own best interest to send multiple RIB-atts per UPDATE (given all other parameters are equal), and to implement the more complex mapping of the UPDATE PDU to the IDRP databases. It is suggested that within the UPDATE PDU, a RIB-ID field be included to distinguish the RIB-att(s) that the UPDATE attributes correspond to. The RIB-ID value could be based on the ordering of the Rib-atts as provided in the UPDATE PDU. Proposal -------- Add to components in first figure clause 6.3 RIB-ID Count (1 octet) RIB-ID (variable) RIB-ID Count: This is a single octet field whose value is equal to the number of RIB-IDs which included in the subsequent RIB-ID field. A value of zero indicates that the default RIB-att is being advertised. RIB-ID: This is a variable length field that contains a list of RIB-att identifiers for the attributes that are described in this UPDATE PDU. 8. Mapping of QOS Maintenance option in Forwarding process Currently, ISO 10747 and ISO 10589 provide different algorithms between mapping an NPDU with the QOS Maintenance option to the appropriate FIB. According to ISO 10589, clause 7.4.2 c) IF the QOS maintenance option is present... c) The IS shall select a forwarding database by mapping the values of bits 3, 2 and 1 of the paramter value as shown in table 1 and shall proceed as follows: 1) If the IS does not support the selected routing metric, the IS shall forward based on the default metric. 2) If the forwarding database for one of the optional routing metrics is selected and the database either does not contain an entry for the Destination Address in the NPDU being relayed, or contains an entry indicating the destination is unreachable using that metric, then the IS shall attempt to forward based on the default metric. 3) Otherwise, forward based on the selected optional metric. Note also that metrics (Expense,Delay,and Error) are supported (No mapping to Capacity.) Meanwhile, IDRP maps the attributes in the QOS maintenance option using a "strong" form of QOS: If there is no exact match between the NPDU options and the defined metrics, the local BIS shall perform the ISO 8373 "Discard PDU Function".. and shall generate an ER PDU with the parameter value set to "Unsupported Option not Specified". Given that ISO 8473 also states that "In those instances where a QOS requested cannot be maintained, intermediate system network-entities shall attempt to deliver the PDU at a QOS different from the QOS requested", it is recommended that the IDRP forwarding process also allow this mapping to a default database. Proposal --------- Change clause 8 b) i) to read: i) If there is no match, then the BIS shall attempt to forward the NPDU based on the default RIB-att. 9. Globally Unique Security Although ISO 8473 provides the Globally Unique Security Option, this option is unsupported in IDRP. If IDRP receives an NDPU with Globally Unique Security, the NPDU will be discarded. Given that there are networks under design which are depending on use of this attribute in an inter-domain environment, it would be advantageous for this attribute to be supported. Proposed Solution ------------------ Provide Globally Unique Security attribute in ISO 10747. Add clauses 6.3 r) GLOBALLY UNIQUE SECURITY This is a well-known discretionary attribute whose variable length field contains the parameters associated with ISO 8473's globally unique security parameter, and is encoded as follows: The use and meaning of the fields is as follows: 1) Length: Given the length in octets of the security label field. 2) Security Label: Contains the value of the security label. If an NPDU contains the globally unique security parameter, the NPDU will be routed according to the security label. Its usage is defined in clause 7.12.18. 7.12.18 GLOBALLY UNIQUE Security GLOBALLY UNIQUE SECURITY is a well-known discretionary attribute that allows a BIS to specify the security level that is associated with a given path, an to limit usage of that path to systems having the NSAP address prefix listed in this attribute. The finest granularity of this control is a single end-system. A BIS shall include this attribute in its UPDATE PDU to indicate that it supports the globally unique security level and that it maintains Adj-RIBs and a Local-RIB distinguished by the indicated globally unique security level. 10. Use of HoldTimer In DIS 10747, the Holdtimer is used for 3 different purposes: 1. When opening a BIS-BIS connection, the holdtimer is used to set the amount of time that will be allowed to set up a connection. After sending an OPEN-PDU to a peer BIS, and receiving an OPEN-PDU from the peer with the incorrect acknowlegement, the BIS will enter the OPEN-RCVD state. If the hold time expires, the connection will be closed. (7.6.1.3 c) 2. After a connection is established, the hold time indicates the amount of time that a BIS may remain in the ESTABLISHED state without receipt of a KEEPALIVE, UPDATE or RIB FRESH PDU from the peer BIS. (7.5.3 j) 3. The transmission of KEEPALIVE PDUs is set to 1/3 the hold time period. (6.5) Depending on the BIS-BIS environment, however, these time periods may be vastly different. On one hand, a BIS may demand a relatively long connection setup period (high hold time period), but send KEEPALIVE frequently (which would demand a low hold time value.) It is recommended that the hold timer indicate the amount of time that a BIS may remain in the ESTABLISHED state without receipt of a KEEPALIVE, UPDATE or RIB REFRESH, and that separate connection initiation and KEEPALIVE timers be allowed.